Nexu API

더블 버퍼링 깜빡임 없는 화면 그리기

더블 버퍼링 화면에 바로 그리지 않고, 메모리 공간에 먼저 그린 뒤 한 번에 출력하는 구조를 사용하면 깜빡임을 거의 완전히 제거할 수 있습니다.
화면에 도형을 그리기 시작하면 바로 눈에 들어오는 문제가 있습니다. 바로 화면이 번쩍이며 깜빡이는 현상입니다. 특히 마우스로 계속 그리거나 자주 갱신할수록 더 두드러지게 나타납니다.

왜 화면이 깜빡이는가

깜빡임의 원인은 단순합니다. 화면을 지우고 다시 그리기 때문입니다.

기본 흐름은 다음과 같습니다.

• 배경 지우기 (WM_ERASEBKGND)
• WM_PAINT에서 다시 그림

이 과정이 반복되면서 사용자에게는 깜빡임으로 보이게 됩니다.

흔한 오해: 코드를 줄이면 해결될까

코드를 줄이거나 그리기 횟수를 줄이는 방법은 근본적인 해결이 되지 않습니다.

• 일부 상황에서만 완화됨
• 구조가 그대로라면 깜빡임 유지

문제는 “얼마나 많이 그리느냐”가 아니라 “어떻게 그리느냐”입니다.

해결 방법: 더블 버퍼링 구조 이해하기

더블 버퍼링은 보이지 않는 메모리 공간에 먼저 그림을 완성한 뒤, 결과만 화면에 한 번에 출력하는 방식입니다.

핵심 흐름은 다음과 같습니다.

1. 메모리 DC 생성
2. 메모리 DC에 전체 화면 그리기
3. BitBlt로 한 번에 출력

이 방식은 중간 과정이 화면에 보이지 않기 때문에 깜빡임이 사라집니다.

실제 구현: 더블 버퍼링 적용하기

case WM_PAINT:
{
    PAINTSTRUCT ps;
    HDC hdc = BeginPaint(hwnd, &ps);

    RECT rc;
    GetClientRect(hwnd, &rc);

    HDC memDC = CreateCompatibleDC(hdc);
    HBITMAP memBitmap = CreateCompatibleBitmap(hdc, rc.right, rc.bottom);
    HBITMAP oldBitmap = (HBITMAP)SelectObject(memDC, memBitmap);

    // 배경 채우기
    FillRect(memDC, &rc, (HBRUSH)(COLOR_WINDOW+1));

    // 실제 그리기
    Ellipse(memDC, g_x - 20, g_y - 20, g_x + 20, g_y + 20);

    // 화면에 출력
    BitBlt(hdc, 0, 0, rc.right, rc.bottom, memDC, 0, 0, SRCCOPY);

    // 리소스 복구
    SelectObject(memDC, oldBitmap);
    DeleteObject(memBitmap);
    DeleteDC(memDC);

    EndPaint(hwnd, &ps);
}
return 0;

추가로 깜빡임을 완전히 줄이려면 다음도 함께 적용하는 것이 좋습니다.

• WM_ERASEBKGND에서 return 1 처리
• 배경을 한 번만 그리도록 통제

이 두 가지를 적용하면 이중으로 지워지는 문제를 방지할 수 있습니다.

마무리

이 단계까지 오면 WinAPI의 핵심 흐름을 모두 경험한 상태입니다.

• 창 생성
• 메시지 처리
• 입력 처리
• GDI 그리기
• UI 컨트롤
• 구조 개선
• 렌더링 최적화

이제 단순 예제가 아니라, 실제 프로그램을 만들 수 있는 기반이 완성되었습니다

구조 개선 : 유지보수 가능한 코드로 리팩토링하기

구조 개선 과정은 선택이 아니라 필수입니다. 메시지 기반 구조 특성상 모든 로직을 WndProc에 넣으면 코드가 빠르게 복잡해지고 유지보수가 어려워집니다. 핵심은 이벤트 분기, 상태 관리, 기능 분리를 명확히 나누는 것입니다.
버튼과 입력창까지 구현했다면 이제 코드가 길어지고 수정이 점점 어려워졌을 것입니다. 이 단계에서는 기능을 확장하기 전에 구조를 정리해야 이후 작업이 훨씬 수월해집니다.

왜 구조 개선 이 필수 단계가 되는가

처음에는 WndProc 하나에 모든 코드를 넣어도 문제가 없어 보입니다. 하지만 기능이 늘어나면 다음 문제가 바로 나타납니다.

• 메시지 처리 코드가 계속 증가
• 전역 변수 관리가 어려워짐
• UI와 로직이 뒤섞임

WinAPI는 메시지 기반 구조이기 때문에 한 곳에 로직이 몰리면 수정 시 영향 범위를 파악하기 어려워집니다.

1 – WndProc은 이벤트 분기만 담당하기

WndProc은 “무슨 일이 발생했는지 판단하는 역할”까지만 담당해야 합니다. 실제 동작은 별도의 함수로 분리하는 것이 핵심입니다.

case WM_LBUTTONDOWN:
    OnClick(hwnd, lParam);
    return 0;

void OnClick(HWND hwnd, LPARAM lParam)
{
    int x = LOWORD(lParam);
    int y = HIWORD(lParam);

    // 실제 처리 로직
}

이렇게 하면 WndProc은 이벤트 라우터 역할만 하게 되어 코드가 훨씬 읽기 쉬워집니다.

2 – 전역 변수 대신 상태 구조체 사용하기

전역 변수는 초기에는 편하지만 규모가 커질수록 문제를 일으킵니다. 상태를 하나의 구조로 묶는 것이 훨씬 안전합니다.

struct AppState
{
    int x;
    int y;
    std::wstring text;
};

상태를 구조체로 묶으면 코드 흐름을 이해하기 쉬워지고, 기능 추가 시 충돌을 줄일 수 있습니다.

3 – 기능별 함수 분리하기

WinAPI 프로그램은 다음 세 역할로 나눌 수 있습니다.

• 입력 처리
• 화면 그리기
• UI 이벤트 처리

void Render(AppState& state, HDC hdc)
{
    TextOut(hdc, 100, 100, state.text.c_str(), state.text.length());
}

void HandleInput(AppState& state, LPARAM lParam)
{
    state.x = LOWORD(lParam);
    state.y = HIWORD(lParam);
}

상태를 참조로 전달해야 변경 내용이 유지됩니다. 값으로 전달하면 수정이 반영되지 않는 문제가 발생합니다.

4 – 클래스 기반 구조로 확장하기

규모가 커지면 구조체만으로는 한계가 생깁니다. 이때는 클래스 기반으로 확장하는 것이 좋습니다.

class App
{
public:
    void OnClick(LPARAM lParam);
    void Render(HDC hdc);

private:
    int x;
    int y;
    std::wstring text;
};

이 방식은 상태와 로직을 함께 관리하기 때문에 프로젝트 규모가 커질수록 효과가 커집니다.
구조를 개선하지 않은 상태에서 기능을 계속 추가하면, 코드 수정 하나가 전체 동작에 영향을 주는 상황이 발생합니다. 반대로 이 구조를 적용하면 기능을 독립적으로 확장할 수 있습니다.
이 단계까지 오면 WinAPI를 단순 학습이 아니라 실제 프로젝트 수준으로 확장할 수 있는 기반을 갖추게 됩니다.

버튼 입력창으로 프로그램 형태 갖추기

버튼 입력창을 추가하면, 단순한 그래픽 프로그램에서 실제로 사용자와 상호작용하는 애플리케이션으로 확장됩니다. 핵심은 컨트롤을 생성하고, WM_COMMAND 메시지로 이벤트를 처리하는 구조입니다.
이전 단계에서 GDI로 도형을 그렸다면, 이제는 사용자가 직접 입력하고 결과를 확인하는 흐름까지 이어지게 됩니다.

GDI 다음에 컨트롤을 배우는 이유

WinAPI에서 화면을 구성하는 방식은 두 가지로 나뉩니다.

그래픽 출력 중심에서 사용자 인터페이스 구성 중심으로 넘어가는 단계입니다. 컨트롤을 활용하면 빠르게 프로그램 형태를 갖출 수 있습니다.

버튼 추가하기: BUTTON 클래스로 클릭 가능한 요소 만들기

버튼은 “BUTTON” 클래스를 사용하여 생성합니다.

#define ID_BUTTON 1

HWND hButton = CreateWindow(
    L"BUTTON",
    L"확인",
    WS_VISIBLE | WS_CHILD,
    50, 50, 100, 30,
    hwnd,
    (HMENU)ID_BUTTON,
    hInstance,
    NULL
);

컨트롤 ID는 매크로로 정의해두는 것이 좋습니다. 버튼에서 발생한 이벤트는 부모 윈도우로 전달되기 때문에, WndProc에서 처리해야 합니다.

입력창 추가하기: EDIT 클래스로 텍스트 입력 받기

입력창은 “EDIT” 클래스를 사용합니다.

#define ID_EDIT 2

HWND hEdit = CreateWindow(
    L"EDIT",
    L"",
    WS_VISIBLE | WS_CHILD | WS_BORDER,
    50, 100, 200, 25,
    hwnd,
    (HMENU)ID_EDIT,
    hInstance,
    NULL
);

입력창은 반드시 핸들을 저장해두어야 합니다. 이후 입력값을 읽을 때 이 핸들을 사용합니다.

버튼 클릭으로 입력값 읽기

컨트롤 이벤트는 모두 WM_COMMAND 메시지를 통해 부모 윈도우로 전달됩니다.

case WM_COMMAND:
{
    if (LOWORD(wParam) == ID_BUTTON && HIWORD(wParam) == BN_CLICKED)
    {
        wchar_t buffer[100];
        GetWindowText(hEdit, buffer, 100);

        MessageBox(hwnd, buffer, L"입력값", MB_OK);
    }
}
return 0;

핵심 구조는 다음과 같습니다.

• LOWORD(wParam): 어떤 컨트롤인지 구분
• HIWORD(wParam): 어떤 이벤트인지 구분

이 흐름을 통해 버튼 클릭 → 입력값 읽기 → 결과 출력까지 연결됩니다.
입력값이 비어 있는 경우는 대부분 입력창 핸들이 올바르게 전달되지 않았거나, 잘못된 변수를 사용한 경우입니다.
이 단계까지 오면 WinAPI에서 기본적인 사용자 인터페이스를 갖춘 프로그램 구조를 완성하게 됩니다.

입력 처리 클릭과 키보드로 창 반응시키기

입력 처리는 “메시지를 받아 상태를 바꾸고, 다시 그린다”는 흐름으로 동작합니다. 이 구조를 이해하면 클릭이나 키 입력에 따라 화면이 변하는 프로그램을 만들 수 있습니다.
Hello World까지 출력했다면 이런 생각이 들 수 있습니다. “이 창은 왜 아무 반응이 없을까?” 실제 프로그램이라면 클릭하거나 키를 눌렀을 때 화면이 바뀌어야 자연스럽게 느껴집니다. 이번 단계에서는 WinAPI 창이 사용자 입력에 반응하고, 그 결과를 화면에 반영하는 흐름까지 이어서 만들어보겠습니다.

Hello World 다음에는 왜 입력 처리를 배워야 할까?

WinAPI 프로그램은 입력을 처리해야 비로소 “동작하는 프로그램”처럼 보입니다.
이전 단계에서는 WM_PAINT 메시지를 통해 텍스트를 화면에 출력했습니다. 하지만 이 상태는 단순히 보여주기만 하는 정적인 화면입니다. 사용자의 행동에 따라 변화가 있어야 실제 프로그램처럼 느껴집니다.

핵심 흐름은 다음과 같습니다.

• 입력 → 상태 변경 → 화면 다시 그리기

이 세 단계가 연결되면서 프로그램이 실제로 반응하기 시작합니다.

마우스 클릭 처리하기: WM_LBUTTONDOWN 이해하기

마우스를 클릭하면 WM_LBUTTONDOWN 메시지가 발생합니다. 이 메시지를 통해 클릭 위치와 이벤트를 처리할 수 있습니다.

case WM_LBUTTONDOWN:
{
    int x = LOWORD(lParam);
    int y = HIWORD(lParam);

    g_text = L"마우스를 클릭했습니다";
    InvalidateRect(hwnd, NULL, TRUE);
}
return 0;

lParam에는 클릭 좌표가 들어 있습니다. LOWORD와 HIWORD를 이용하면 X, Y 값을 분리할 수 있습니다.
중요한 점은 단순히 메시지를 처리하는 것이 아니라, 상태값을 바꾸고 화면 갱신까지 연결해야 한다는 것입니다.

키보드 입력 처리하기: WM_KEYDOWN 이해하기

키보드 입력은 WM_KEYDOWN 메시지로 처리합니다. 단, 창이 포커스를 가지고 있어야 메시지가 들어옵니다.

case WM_KEYDOWN:
{
    if (wParam == 'A')
    {
        g_text = L"A 키를 눌렀습니다";
        InvalidateRect(hwnd, NULL, TRUE);
    }
}
return 0;

wParam에는 눌린 키 코드가 들어 있습니다. 이를 통해 특정 키 입력에 따라 동작을 다르게 만들 수 있습니다.
여기서 자주 발생하는 실수는 창에 포커스가 없는 상태에서 키 입력을 테스트하는 것입니다. 반드시 창을 한 번 클릭한 후 입력을 확인해야 합니다.

입력 결과를 화면에 반영하는 흐름 만들기

입력 처리의 핵심은 “값 변경과 화면 갱신은 별개”라는 점입니다.

다음 흐름을 반드시 기억해야 합니다.

• 입력 메시지 수신
• 상태값 변경 (예: g_text)
• InvalidateRect 호출
• WM_PAINT에서 다시 그림

case WM_PAINT:
{
    PAINTSTRUCT ps;
    HDC hdc = BeginPaint(hwnd, &ps);

    TextOut(hdc, 100, 100, g_text.c_str(), g_text.length());

    EndPaint(hwnd, &ps);
}
return 0;

이 구조를 통해 클릭이나 키 입력에 따라 화면 텍스트가 바뀌는 프로그램을 만들 수 있습니다.
많은 초보자가 “값은 바뀌었는데 화면이 그대로인” 문제를 겪습니다. 대부분 InvalidateRect 호출이 빠진 경우입니다.
이 흐름을 이해하면 WinAPI에서 입력과 화면 출력이 어떻게 연결되는지 명확해집니다. 이제 단순 출력 프로그램을 넘어, 사용자와 상호작용하는 기본 형태를 갖춘 상태입니다.